上下文工程：Agent 成败的关键
在 Hello-Agents 里，真正的重头戏——甚至我觉得也是整个 Agent 开发成败的关键——就是第九章《上下文工程》。
1. 上下文工程 vs 提示词工程：别把它俩当一回事
一说“上下文工程”，就绕不开“提示词工程”。我甚至猜有些同学会把两者当成同一个东西。
刚接触 AI / LLM 的时候，我也刷到过铺天盖地的文章教人怎么写提示词。我自己笔记里也存过一个提示词工程教程，但快速浏览后我就没太大兴趣继续深挖。不是因为它不重要，而是因为：只要你认真想清楚你到底想从 AI 那里得到什么回答，你自然会反过来优化自己的提问方式与提供的信息。
我之前写过一篇文章：和AI共事，比学习提示词重要100倍。我并不是说提示词工程一无是处，而是我更倾向于：先把问题想清楚，然后在对话中不断校准；而不是指望第一次就写出一个“完美的结构化提示词”，一次性换来“完美答复”。
你跟人交流也不会上来先掏出一份稿子念一遍，然后期待对方立刻给出完美回应吧？
2. 图里能看出的区别：上下文工程关注“塞什么”，提示词工程关注“怎么说”
（此处建议配你提到的那张图）
从图里你会更直观地看到：上下文工程更在意的是——你组织哪些信息塞进 prompt。
- 哪些信息是固定要塞的？
- 哪些信息要动态拼凑？
- 哪些需要压缩？
- 哪些最好原样带入？
当然，提示词工程也强调“结构化”，避免 LLM 在过长 提示词 里迷失注意力——这一点在上下文工程里同样成立。
我自己的理解是，本质区别在这里：
- 提示词工程 更像一种手工艺：依赖单个提示词 的精巧设计，但很难规模化。
- 上下文工程 才更配得上“工程”二字：它把调用 LLM 之前的准备过程标准化、流水线化，目标是工业化生产。
- 关键在于：只懂提示词，你的单步能力可能很强，但一旦进入多步流程，就容易跑偏；只有掌握上下文工程这种系统化思维（怎么管理历史、怎么注入知识、怎么调度工具），你才能构建出一个不一定“惊艳”，但至少能稳定跑多步的 Agent。
3. 为什么必须做上下文工程？
两个原因最直接：
- 上下文窗口有限
- Token 是要钱的
说到“上下文窗口有限”，我一开始其实完全没概念。我只知道：打开 Deepseek 网页，贴个文件进去，聊着聊着它就提示到上限，让我重开窗口。别人也会说 Deepseek 小、Kimi/Qwen 大、ChatGPT/Gemini 更大……但“更大”到底是什么概念？它怎么被消耗？我当时根本没认真想过。
直到有一次（知乎直答的前身），它第一轮回答得很精彩。我第二轮追问时图省事，没有补充太多信息。按理说结合上一轮上下文很容易答，但如果只看我的那一句追问，确实有点突兀。结果它居然给了我一个和上一轮完全不相关的答案。
我当时很疑惑：怎么这么快就“忘了”？这才第二轮，也没到上下文窗口上限啊？
从那次开始我才真正注意到“上下文窗口有限”这几个字。即便是在网页端聊天，要让 AI “记得你上面说了什么”，系统也要不断把之前聊天记录压缩，再加上你这次输入，一起喂给模型。聊到最后，压缩后的历史 + 本轮输入 + 本轮输出 一起超限，于是这段对话就进行不下去了。
4. 做 Agent 时，窗口里的“竞争”更激烈
当你开始设计一个更复杂的 Agent，窗口里的“竞争”会比普通聊天激烈得多（可以再看看上面的图）：
- System Prompt（系统提示词）：告诉 AI 它是谁、要干什么，通常就要占几百甚至上千 token。
- 工具定义：如果 AI 能联网、能写代码，工具说明文档也会吃掉大量 token。
- RAG 检索回来的知识：搜索回来的文件，很多时候不是整篇塞进去，而是先检索最相关的几段，再把这些片段塞进上下文。
**这意味着：**真正留给“对话历史”的空间，往往比你想象得小得多。也正因为如此，你才需要“上下文工程”——在这些彼此竞争的信息之间做取舍、做组织、做压缩。
班门弄斧，希望能给大家提供更多思路。下期见。
加载中...